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Amendments to the Specification 

Replace the paragraph beginning at page 6, line 18 with: 

Computer ICQ may also have input devices such as a keyboardj mouse^ pen, voice 
input device, touch input device, etc. Output devices such a3 a display il8 -1+6, speakers, 
a printer, etc. may also be included. All these devices are well known in the art and need 
not be discussed at length here. 

Replace the paragraph beginning at page 8, line 20 with: 

Referring to FIG.5, another example of a UI may be used in an embodiment of the 
invention is shown. The UI, generally labeled 500, includes a first pull down menu 502 
and a first explanation field 503, a second pull down menu 504 and a second explanation 
field 505, and a text input area 506. The UI 500 further includes an OK button 508, a 
cancel button 510, and a help button 512. The first pull down menu 502 allows the user 
to choose an action to perform, such as shutting down the computer. Other possible 
actions listed in the pull down menu 502 include logging off a network, or restarting the 
computer. The first explanation field 503 gives the user a textual explanation of the menu 
Item. The second pull down menu 504 allows the user choose a reason for performing the 
action chosen in the first pull down menu 502. For example, if the action chosen in the 
first pull down menu 502 is "shut down," then the choice given to the user in the second 
pull down menu 504 may include, for example, hardware maintenance, operating system 
configuration, software installation system failure, power failure and system hung. The 
second explanation field 505 gives the user a textual explanation of the chosen menu 
item. The text input area 506 504 allows the user to enter additional comments such as 
"power failure vras building-wide." 

Replace the paragraph beginning at page 10, line 1 with: 
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There are a variety of ways in which a user-mode snapshot may be implemented. 
Referring to FIG. 13, one example of a user-mode snapshot will now be illustrated and 
described. In this example, a computer 1300 has just experienced an unexpected 
shutdown, as indicated by the shutdown reason entered by a user 1302. Prior to shutting 
down, the computer 1300 takes a snapshot 1304 of its user-mode processes and stores it 
on its mtemal hard disk 1306. The snapshot 1304 450* is an extensible mark-up 
language (XML) file that includes per process parameters 1310 for each user-mode 
process, pagefile parameters 1312, and system parameters 1314. The per process 
parameters 1310 describe those conditions that are relevant to a single process, and may 
include one or more of the following pieces of information: 

• User time: The amount of time in seconds that the process kept the processor in 
user mode. 

• Kernel time: The amount of time in seconds that the process kept the processor tn 
kernel mode. 

• Working set: The amount of memory the process was using at the time tlie 
snapshot was taken . 

• Total page faults: The number of times the processor was forced to go to virtual 
memory on the computer's hard drive. 

• Bytes committed: The number of bytes of memory the process had reserved at the 
time of the snapshot, regardless of whether all of it was actually used. 

• Process priority: The priority of the process vis-i-vls the rest of the processes. 

• Number of handles: The number of handles, or pointers to blocks of memory 
being used by the process. 

• Number of threads: The number of threads that were defined within the process at 
the time the snapshot was taken. 

Replace the paragraph beginning at page 15, line 14 with: 

Referring to FIGS. 9 and 1 0, another example of steps that may be taken to collect 
shutdown information for a computer running the WINDOWS XP brand operating 
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system will now be described. It is assumed that this procedure occurs during a reboot 
operation following an unexpected shutdovN^n of the operating system. It is understood 
that these steps are £Lpp1icabte to non- WINDOWS XP implementations as well, even 
though described in the context of WINDOWS XP, At step 901 (FIG. 9), the user logs in. 
At step 902, the collector module 610 (FIG. 6) checks the system database 640 to 
determine whether shutdown reason collection has been enabled* If it has not been 
enabled, then the flow proceeds to step 91 1, at which a conventional reboot ensues. If 
shutdown reason collection has been enabled, then the collector module 610 retrieves the 
list 612 of shutdown reasons, and retrieves any custom-defined shutdown reasons from 
the system database 640, and displays the reasons on a UI 1000 (FIG. 10) at step 903» At 
steps 904, 906 and 907 90S — 907, the system manager module 610 waits for the user to 
either select a predefined shutdown reason from the pull-down menu, or enter his own 
reason in the comments box. Optionally, the user may be sent back to step 901 after a 
two minute time-out. After the user selects or enters a reason, the collector module 610 
enables the OK button (step 908). After the user clicks OK (step 909), then the collector 
module 610 calls the log file helper function directly and stores the entered reason in the 
repository 620 (step 91 0). At step 91 1, the WINDOWS XP operating system resumes its 
normal booting operation. 

Replace the paragraph beginning at page 16» line 11 with: 

Referring to FIG. 1 1 , yet another example of an architecture that may be used in 
an embodiment of the invention is shown. The architecture comprises a first computer 
system 1 100 that includes a shutdown reason collector module 1110 having a list 1 1 12 of 
predefined shutdown reasons, a user interface 1 130, a snapshot modul e 1 1 72, and an 
optional system database 1 140. The architecture further comprises a computer network 
1 1 50, and a second computer system 1 1 60 having a memory 1 1 6 2. and a snapshot module 
1172. The memory 1 162 fiirther includes a shutdown reason repository 1 170, which may 
be a log file. The first and second computer systems may communicate with one another 
over the network 1 150. The system database 1 140 may include predefined shutdown 
reasons in addition to those in the list 1112 of the collector module. A user at the first 
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computer system 1 100 may remotely shut down a program on the second computer 
system 1 1 60 via the user interface 1130. The user interface 1 1 30 also gives the user an 
opportunity to enter a reason for the shutdown. The collector module 1110 check$ the list 
1 112, as well as the system database 1 140 to ensure that the entered reason is 
recognizable. If, based on the entered reason, the collector module 1110 determines the 
shutdown to be unplanned, then the collector module 1110 invokes the snapshot module 
1 172, which takes a snapshot of the state of the user-mode processes and saves the 
snapshot on the non-volatile memory of the computer system 1 160. The collector module 
1 1 10 then stores the shutdown reason remotely in the log file 1 1 12, Storing the shutdown 
reason on the second computer system 1 160 is advantageous, since it is a program on the 
second computer system that is being shutdown, even though the action was initiated 
from the first computer system. 
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